Autoprefixing

🔗

It can be challenging to remember which vendor prefixes you have to use for specific CSS rules to support a large variety of users. Autoprefixing solves this problem. It can be enabled through PostCSS and the autoprefixer↗ plugin. autoprefixer uses Can I Use↗ service to figure out which rules should be prefixed and its behavior can be tuned further.

Setting up autoprefixing

🔗

Achieving autoprefixing takes a small addition to the current setup. Install postcss-loader and autoprefixer first:

npm add postcss-loader autoprefixer -D

Add a fragment enabling autoprefixing:

webpack.parts.js

exports.autoprefix = () => ({
  loader: "postcss-loader",
  options: {
    postcssOptions: { plugins: [require("autoprefixer")()] },
  },
});

To connect the loader with CSS extraction, hook it up as follows:

webpack.config.js

const cssLoaders = [parts.tailwind()]
const cssLoaders = [parts.autoprefix(), parts.tailwind()];

The order of the loaders matters since autoprefixing should occur after Tailwind finishes processing. The above gets evaluated as autoprefix(tailwind(input)).

PostCSS supports postcss.config.js based configuration. It relies on cosmiconfig↗ internally for other formats.

parcel-css-loader)↗ is a faster alternative for PostCSS. If you don’t rely on PostCSS plugins, it alone would be enough for autoprefixing your CSS.

Defining a browserslist

🔗

autoprefixer relies on a browserslist↗ definition to work.

To define which browsers you want to support, set up a .browserslistrc file. Different tools pick up this definition, autoprefixer included.

Create a file as follows:

.browserslistrc

> 1% # Browser usage over 1%
Last 2 versions # Or last two versions
IE 8 # Or IE 8

If you build the application now (npm run build) and examine the built CSS, you should see that CSS was added to support older browsers. Try adjusting the definition to see what difference it makes on the build output.

You can lint CSS through Stylelint↗. It can be set up the same way through postcss-loader as autoprefixing above.

It’s possible to define a browserslist per development target (BROWSERSLIST_ENV or NODE_ENV in the environment) by using [development] kind of syntax between the declarations. See browserslist documentation↗ for further information and options.

postcss-preset-env↗ uses a browserslist to determine what kind of CSS to generate and which polyfills to load. You can consider it as the @babel/preset-env of CSS. Latter is discussed in more detail at the Loading JavaScript chapter.

Conclusion

🔗

Autoprefixing is a convenient technique as it decreases the amount of work needed while crafting CSS. You can maintain minimum browser requirements within a .browserslistrc file. The tooling can then use that information to generate optimal output.

To recap:

• Autoprefixing can be enabled through the autoprefixer PostCSS plugin.
• Autoprefixing writes missing CSS definitions based on your minimum browser definition.
• .browserslistrc is a standard file that works with tooling beyond autoprefixer.